Progress
0 / 10
Directive (EU) 2022/2555 · Article 21(2)

NIS2 Cybersecurity Measures
Self-Assessment Checklist

The ten minimum measures required of essential and important entities under NIS2. Use this checklist to assess your current status. Tick each item when you can demonstrate documented, implemented, and reviewed measures — not just intent.

Art. 21
2(a)
a Risk Analysis & Information Security Policy

You have a documented policy covering how your organisation identifies, assesses, and manages risks to your network and information systems. The policy is approved by management, reviewed periodically, and based on a structured risk analysis — not a generic template.

Example

An annual risk assessment session with department heads produces a risk register. The results inform a written information security policy, signed by the board, that is reviewed whenever significant changes occur — a new system, a new supplier, a reorganisation.

Art. 21
2(b)
b Incident Handling

You have documented procedures for detecting, reporting, responding to, and recovering from security incidents. Staff know what constitutes an incident, who to notify, and what steps to follow. Procedures also cover the mandatory reporting obligations to national authorities under NIS2.

Example

A one-page incident response procedure defines four severity levels. For significant incidents, it names the responsible person, sets a 24-hour internal escalation deadline, and references the 72-hour notification requirement to the national authority. The procedure is tested once a year in a tabletop exercise.

Art. 21
2(c)
c Business Continuity, Backup & Crisis Management

You have a business continuity plan that covers cyber scenarios. It defines recovery time objectives (RTO) and recovery point objectives (RPO) for critical systems, documents your backup regime, and assigns responsibilities for crisis management. The plan is tested and kept current.

Example

Your BCP includes a ransomware scenario: systems are unavailable for 48 hours. The plan defines which processes can continue manually, who contacts customers, and how to restore from backups. Backups are stored off-site, tested quarterly, and the maximum acceptable data loss is documented as 24 hours.

Art. 21
2(d)
d Supply Chain Security

You assess the cybersecurity practices of your direct suppliers and service providers. You know which suppliers have access to your systems or data, what your dependency on them is, and what is contractually agreed regarding security. The security standard you apply to yourself applies equally to your supply chain.

Example

You maintain a supplier register with a risk profile per vendor. Critical IT suppliers complete an annual security questionnaire. Contracts include minimum security requirements and an obligation to notify you within 24 hours of a security incident that may affect your systems.

Art. 21
2(e)
e Security in System Acquisition, Development & Maintenance

Security requirements are built into how you procure, develop, and maintain systems — not added afterwards. This includes a process for identifying and addressing vulnerabilities in software and hardware you use, and a policy on responsible disclosure of vulnerabilities you discover.

Example

Before deploying new software, your IT team runs a security review checklist. Vendors are required to provide patch timelines for known vulnerabilities. A process exists to apply critical patches within 72 hours and to track open vulnerabilities until resolved.

Art. 21
2(f)
f Effectiveness Assessment of Cybersecurity Measures

You have a documented process to periodically evaluate whether your security measures are actually working. This is not a one-off exercise — it is a recurring review cycle (PDCA) that produces findings, decisions, and evidence. Compliance is not the goal; demonstrated effectiveness is.

Example

An annual internal audit reviews a selection of security controls against the risk register. Findings are reported to the board with a remediation plan. The results of the previous year's audit are compared to track improvement over time.

Art. 21
2(g)
g Cyber Hygiene & Cybersecurity Training

All staff are trained on basic cybersecurity practices relevant to their role. Training is recurring, not a one-off onboarding activity. You can demonstrate that training took place and that it covered current threats. A culture exists where employees feel safe reporting suspicious activity.

Example

New employees complete a security awareness module within their first two weeks. All staff receive an annual refresher covering phishing, password hygiene, and what to do when something looks wrong. Participation is logged. Phishing simulations are run twice a year to test awareness in practice.

Art. 21
2(h)
h Cryptography & Encryption Policy

You have a documented policy on the use of cryptography, covering when and how encryption is applied to data at rest and in transit. The policy specifies approved algorithms and key management practices. It is reviewed when technology or threat landscapes change.

Example

Your policy states that all data classified as confidential must be encrypted at rest using AES-256, and that all external data transfers use TLS 1.2 or higher. Laptops are encrypted by default. Encryption keys are managed centrally, with access restricted to authorised personnel.

Art. 21
2(i)
i Human Resources Security, Access Control & Asset Management

Access rights are granted on a need-to-know basis and reviewed regularly. Joiners, movers, and leavers are handled through a formal process that includes timely revocation of access. You maintain an up-to-date register of information assets and know who is responsible for each one.

Example

HR notifies IT on the last day of employment. The IT checklist for leavers covers revocation of all accounts, return of devices, and a brief handover conversation about tools used. Access rights are reviewed per department every six months. A simple asset register lists systems, data classifications, and owners.

Art. 21
2(j)
j Multi-Factor Authentication & Secured Communications

Where appropriate, multi-factor authentication (MFA) is in place for access to systems and data — particularly for remote access, privileged accounts, and critical applications. Sensitive internal communications use secured channels. Emergency communication systems are documented and tested.

Example

MFA is mandatory for all remote access via VPN, all cloud applications, and all accounts with administrative privileges. A policy defines which communication channels are approved for sharing confidential information. In the event of a system outage, an offline contact list and fallback procedure exists for crisis communication.